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I. Motivation for the Restructuring 


During our work in providing some new features for the Air 
Force, we needed to create anew type of device driver which 
would be controlliea by the I[/0 Coordinator. However, due to 
the current structure of fhe driver software, we found this 
task very difficult. Specificaily, it would be necessary to 
introduce a new operator response at [0 Daemon initiatization 
time and write new software to be executed for the remainder 
of the processe Limitations within existing modules, due to 
the assumptions about possibile agevice fypes and how they would 
be controited, prevent their use in new drivers. 


It occurred to us that if we are having this trouble now, 
others will nave the same problem in the future as more 
devices, which could be controlled by a device driver, are 
adaea to the system. For example, the MIT/IPC effort to write 
a spooling fape dim with a command interface shows one attempt 
to sada a tape driver within the current) structure. In the 
future we may want fo add plotters, COM or other devices, 
which may be controlied by queued requests. 


Therefore, now that we have a need for anew driver type, it 
will be easier to generalize tne driver structure at this time 
“rather than rewrite even more software in the future. This 
MTB adaresses this generalization with the following goats? 


1. Allow the easy addition of new driver software for new 
agevices (lor device ciasses) without recompiling existing 
soffware or changing the operator interface except (for 
device specific functions. 


2. Separate the driver control software into generic 
functional modules for easy maintenance and sharing or 
tailoring to new ariverse 


3. Generalize the specifications of devices and device classes 
within Lo _daemon_parms allowing parameters to determine the 
control module which will be calied. 
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-1- 


MTB-444 Multics Technical Bulietin 


IIeProbiems with the Current Oriver Software 


The statements made in the first paragraph were very general, 
so fhe foltowing is presented as further jJustificatlon. The 
reader may wish to 100k af the source programs in’ 
bound_ilodd_eSearchive in the toois tibrary to clarify some of 
the specificse 


1. All modules of the driver software assume either print or 
punch device specifics throughout. Extensive checking of 
new “switches* would be required if this software were to 
be used for new devices. 


22 Tne format of a user request assumes printer or punch 
control functions which may not apply to other devices. 
(Only a smati amount of cata in the front of the structure 
is shared by the I0 Coordinator.) 


3.e Current data areas in iodd_static assume that there wiit be 
no more than two logical devices per physical device (eegey 
the printer and punch of a mohawk). Tnis makes fhe 
acaition of new multi-function devices more difficult. 


4. Only the remoté_ module knows how to find the two logical 
agevices associated with a multi-function device using the 
“remote_tab™” (which also timits the togical devices to 
“ort uname™ and “pun_name"™) This forces the single 
function ana multi-function device initiatization 
algoritnms to be completely different. The limitation of 
multiefunction devices to remote_ Is aiso seen in 
lo_adaemon_par mse 


5. The module input _cmd_-« which does general driver command 
processings assumes that only remote_ could have aevice 
specific operator commands. 


6. To share code between the oprint and punch requests for 
local ana remote drivers (and for historical reasons), the 
module outputf_request_ carefuliy formats printer head and 
tail sheets for punch reauests and writes them through the 
discard_output_ aim. 


7. The module iodd_tisten_» which dispatches a user request 
(from the coordinator) to be processed by the driver, 
assumes that onity one modul€ kKknowS how to handle the 
request, no matter what device is to be used. 


In summary, the [0 daemon driver is structured as an output onty 
driver which knows how to print and punch with on site or remote 
(mohawk) deviceSse Tne diminame in io_daemon_parms atflows some 
flexionility,s, but not enough for completely new functions with the 
existing software. 
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III.Proposed Changes 


At initialization time for any I0-eSysODaemon the operator is 
asked whether the process is to be a “coordinator, driver, 
remote or cards." This witli be changed to allow only 
“coordinator or ariver“, moving the distinction between remote 
and focal drivers until ijater in fhe process so we can use 
some common general procedures for assignment of cevices and 
device classes. (“cards does not have to run as 
TO0.SysDaemon. The removal of the “cards” option is the 
Subject of another MTB.) 


Tne current iodd_overseer_ wiil take on additional functions 
from io_aaemon_driver_,» remote_,» and driver_init i+ providing 
centralization of ali initializafion code and ai uniform 
approach to searching the lod_device_tab. This is a necessary 
step since the “remote™ response has been removed (above) and 
we must now determine the existence of multipie fogical 
devices differentiy. 


To accomplish this, we will introduce the concepts of major 
and minor aevices To io_daemon_parms and to the 
lod .device_tabe. A “major sevice” is a generic name associated 
with a physical device. A “minor device” is a generic name of 
a logical device associated with a major device. There may be 
up fo ten (10) minor devices per major device. (Ten is = an 
arditrary number chosen to limit tabie size and still altow 
filexibliity.) . 


Each major cevice corresponds fo a physical oiece of hardware 
attacned to the process through a physical I/0 or TTY channel. 
The per aevice attributes such as channel, dim, driver module, 
device diat id (for remote devices), and control terminal dial 
ia (see MTB 129)+ are associated with the major device. Each 
minor device then has the device type and default device class 
associated with it. 


Now, when the operator is asked to give the “aevice name and 
optional aevice class,” he will specify the major device name 
(assume no device ciass for the present). The module 
ioad_overseer _ will then proceed by requesting the [0 
coordinator to associate each of the minor devices ahich 
belong to the major device with the driver process. Separate 
Griver status segments will be created for each minor device. 
The driver may now behave as separate togical grivers for each 
minor device at its discretion. The driver may even ignore 
one or more of the minor aevices.s This does not tie up 
resources unnecessarily since they are all part of the same 
physical device and can only be attached fo one process at a 
time. 
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There are two cases which can arise when the operator 
specifies tne optional device ciass. First, when there is 
only one minor device for the major device (e.ge, a printer 
connected to the IOM) the specified device class will override 
the default device class defined in lo_daemon_parms. There is 
no ambiguity in the operator"*s intent In this case. The 
secona case occurs when there are mulfipte minor devices for 
the major devicee Currentiy, onty the cefauit device class 
for each device may be usede Since we do not know to which 
minor device the optional device ciass should apply, we 
propose that the operator obe asked if the specified aevice 
class is to be associated with each minor device, in turn, 
giving the operator the ability to choose a different device 
class or retain the aefault for each minor device. This 
approach is chosen to simplify the operator interface for the 
common situation (in fact, it will not change at alt) and 
still alttow the operator to switch the processing of any 
device class to any driver which can handle if, local or 
remote. 


A new Gata item will be adaed to lo_daemon_parms, cailed 
“driver_module”. This wiil be associated with the major 
aevice and will define the program to be cattedq by 
ioddad_overseer_ after the initial driver-coordinator protocols 
are completed. By convention, there will be standard entry 
polnt names in the ariver moauie for initiatization, request 
processing, commana processing and condition nandling. Entry 
variables will be aaded to iodd static so each of the common 
sriver subroutines (@egeys ioda_listen_ and Input _cmd_) can 
have standara calls to perform driver specific functions. 


New driver modules may need new data from io_daemon_parms. 
Therefore, to avoid modifying several programs and data 
structures for each new driver, the method of specifying the 
major ana minor cevice attributes in the Lo_aaemon_parms file 
needs to be generalized. Only those attributes whicn are 
needéag auring the common initialization of ali drivers wiil 
have kKeyworas in the parms filee Those attributes which may 
be more dynamic, on a per driver module basis, will be 
described by a quoted String after the new keyword “args"™. 
This altows the adagition of new driver control moaules to be 
completely parameteri Zedee end recompilation Should be 
necessarye 


The format of the user request aata structure which is stored 
in the message segment must also become more general. This 
wild allow aevice options ang ariver opfions to be tailored to 
each driver module ratner than changing one inciude fite and 
reconplling atl modules which use it (currently there are nine 
(9) external procedures which reference dprint_msg.incl.pii). 
We will establish a standard hneader sfructure which wilt 
define that part of the request data which must be Known by 
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the coordinator as well as aft drivers. The “print se punch” 
variabie will be changed to indicate the driver modute which 
is expected to perform the request. Only the driver module 
and the command setting the vaiue need fo agree on the vatue 
(but if must be unique among driver moduies). Each driver 
module will check to ensure that the request is meant for that 
particular driver. Then the remainder of the request data can 


be interpreted on a per agriver modute basise The coorainator 


[Ve 


does not care how tong the request is; it onty needs the 


time, pathname, delete switcn and version of the request 
neagere 


Summary 


These proposed changes provige the structure needed to 
completely generatize the driver software. A new type of 
device driver can be added by writing a driver moauie which 
meets the conventions and knows how to control the device. 
Then the lo_daemon_parms file can be edited by an 
administrator to Iinclucge the new device, device class and 
other attribufes. 


The operator interface will not change for the new oriver 
except for new driver specific commands. Each driver can make 
use of the same overseer, which wlll handie all iinitiat 
arivere-coorainator protocol. Some of the ariver subroutines 
can be directly used by the new driver modute without changes$5 
others can be easily tallored to meet new requirements. 


These changes imply thaf almost every module of the current 
driver process will be either rewritten, restructured or 
removede Oriver mocuies for controiling the oprinter, punch 
and mohawk devices will nave to be written. At installation 
time, al! driver modules and lo_daemon_parms will-have to be 
repiacegq since they will now be incompatibie with older 
versions. 
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APPENDIX I 


I0 DAEMON PARMNS KEYWORD LIST - ORDERED BY OCCURENCE 


/* PL/I style comments may appear anywhere in the parms file */ 


There are two keywords which specify global values for the 10 
coordinator ana must appear at the beginning of the parms file? 


Time: Defines the time in minutes that each 
completed request wil! be saved to allow for 
restartinge Normality, a delete option witli 
not be completed until after this time has 
elapsed. . 


Max _ queues? Defines the maximum number of message segment 
queues to be created or read for each queue 
group defined. 


Tne next group of keywords are used to define tne aevices which 
Griver processes may uUS@€. The device data is used oy fhe [0 
coordinator to bulla the “device_table™. Ali device definitions 
must appear ahead of the agevice ciass definitions. 


Device? Defines the name of a major device 
(required - 32 char max) 


driver_modules Defines the pathname or search name of the 
program which runs the device 
(required - 168 char max) 


args: Defines an arbitrary character string for the 
driver module to decode which describes the 
major device. (optional - 128 char max) 


channel . Defines the [OM channel of the device _ for 
direct attachment by the process. This must 
be specified if tne dev _dial_Id keyword is 
omitted and mus ft be omitted if the 
Gev_dial_id is specifiedg. (8 char max) 


dev_dial_id? Defines the dial_id to be used if the device 
is to be diated to the process over a tty 
channel. Immediate attachment to a hard 


wired ffy channel wiif be specified in the 
gial table if aesired by the site. This 
keyword may not ve specified if tne channel 
keyword is used. (8 char max) 
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ctt_diat_idat 


cti_devices: 


minor_devices: 


args: 


gefaulf_citass? 


Jikes: 


Defines the diat ld to be used for the 
control terminal to be ciaied to the processe 
Optional - if omitted, no control terminal is 
requirea for ; the driver. 
(optionaf - 8 char max) 


Defines the device name expected for the 
attachment of tne controt terminal. Exampie: 
cti1 for the message coordinator, neti03 for 
the arpa net, tty142 for the ON355. This 
keyworc is primarliy inciudea for the message 
coordinator since there will be no check to 
ensure that this is the actual channel 
assigned. (optionai - 8 char max) 


Defines the name of a minor device associated 
with the last named major device. If omitted, 
the minor device name is taken to be the same 
as that of the ma jor device. 
(optional - 32 char max) . 


After the minor device keyword, args defines 
another arbitrary character string used by 
the driver module to describe the minor 
device. Tnere may be one args keyword per 
minor device. If omitted for any minor 
Gevice, a null character string is assumea. 
{optionai - 1@8 char max) 


Defines the defauit device ciass to be used 
for this minor device. If omitted, the 
operator must specify the aqevice ciass during 
initialization. {optional - 32 char max) 


This keyword is used fo reduce the amount of 
text in the parms file when there are several 
major devices with similar attributes. Aili 
missing attributes in the specification of 
the major device, including minor device 


names, are taken from the major device name 


which = is the value of the keyword. 
(optional - 32 char max) {[Note? fhe major 


-gdevice named must have been previously 


specified if the file.) 


The following Keywords define the device classes used by fhe 10. 


coorcinator - ang 


drivers. The device ctass definitions must 


follow the definitions of the devices fo help simplify the 
parsing of the parms file. 
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device? 


driver_useria’ 


accounting? 


queue_groups 


min access_class: 


Max _access_class’ 
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Defines the name of a dynamic device classe 
(required - 32 char max) 


Defines a minor device which may process 
requests of the last named Device_ciass. One 
or more instances of this keyword must be 
associatea with a device classe The value is 
of the form major.minor to distinguish 
between minor devices of the same name in 


aiftferent major devices. If only one 
component is specified as the value, then 
majoremajor is assumede 


(requirea - 65 char max) 


Defines the onfy process group id which may 
be used to handte requests in thls device 
classe If omitted, [I0.SysDaemon is assumed. 
A personid of * Is atiowed, buf the projectid 
must be specified. {optional - 32 char max) 


Defines the pathname of the accounting 
procedure to oe used for the driver. If 
omitted, or if the vatue of "systeam” is 
specified, the standard system accounting 
procedure wiltt be used. The accounting 
proceaure specified must be found dauring 
process initialization, or the driver wiil 
abort. (optionat - 168 char max) 


Defines the message segment queues to be used 


for requests in this device ciass. If 
omitted, the queue group will be taken to obe 
the same as the device class. Example 


printer means use the oprinter_NemS queues. 
(optional - 32 char max) 


Defines the lowest access class request which 
a driver of this device class may process 
from the specified queue groupe. If omitted, 
the system_low access ciass will be assumed. 
The string must be acceptable to the 
convert_authorization_._ subroutine. 
(optional) . 


Defines the highest access class request 
which a driver of this device class may 


process from the specified queue group. The 
access authorization of the driver must be 
equal or greater than this vatue. The 


max _access_class must be equal or greater 
than the min_access_class according to the 
ruies of fhe access isolation mechanism If 
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min banner’ 


End: 
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omitted, the value of min _access_cilass is 
assumed. .The string must be acceptable to 
the convert_author ization_ subroutinee 
{optional) 


Defines the ftowest access class to be used in 
marking the output generated by a driver 
process. (f omittea, the value of 
Min access _ciass is assumed. The string must 
be acceptable to the convert _authorizatlon_ 
subroutine. {foptional) 

i 


This keyword has no vaiuve associated with it. 
It onty serves to define fhe end of fhe parms 
file. (required) 


